1. Field of the Invention
The present invention relates to a technology of defending a Distributed Denial-of-Service (DDoS) attack, and more particularly, to a technology of detecting and responding to an application layer (layer 7)-based slow DDoS attack that causes connection resource consumption using only a small amount of traffic.
2. Description of the Related Art
A Distributed Denial-of-Service (DDoS) attack refers to an attack by a plurality of unspecified attackers to send a large amount of data, to sharply reduce a performance of a target network or system, so that a service provided by the system may be unavailable, with intent to interrupt a normal service of the system.
In the past, Transmission Control Protocol (TCP)/User Datagram Protocol (UDP)/Internet Control Message Protocol (ICMP) flooding L3/L4 attacks that consume resources, such as a network bandwidth, a Central Processing Unit (CPU) of a server, a memory, and the like, mainly occurred. However, the above attacks were incapacitated due to development of an anti-DDoS solution.
However, recently, a DDoS attack in an application layer L7 that may not be incapacitated by the anti-DDoS solution, is increasing.
In particular, among application layer L7 DDoS attacks, a fast attack of a flooding, such as a Hypertext Transfer Protocol (HTTP) Get flooding, used in a famous DDoS attack tool, namely a NetBot Attacker, tends to be changed to a slow attack, such as a slowloris, or a r-u-dead-yet (RUDY)/OWASP HTTP post tool.
This is because such a change may be easily detected, since an L7 flooding attack in addition to L3/L4 attacks need to ensure a large number of zombie Personal Computers (PCs), and since a large amount of traffic are caused during an attack.
Most of application layer L7 DDoS attacks use a weak point of an HTTP, and two types of slow attack causing L7 connection resource consumption are known as follows:
In the present specification, the term ‘connection’ may be used interchangeably to the term ‘session’, when necessary.                1. Slow request headers: Slowloris attack        2. Slow request bodies: RUDY/OWASP HTTP post attack        
A slowloris attack using slow request headers refers to a DDoS attack tool against an Apache web server. In other words, the slowloris attack refers to an attack to transfer an incomplete HTTP Get Request message to a server, to consume connection resources of a corresponding web server in a short time, and to enable a service to be unavailable. When connection setting is performed through a legal TCP 3-way handshaking process, an HTTP Get Request message may be transmitted, however, a keyword ‘CRLFCRLF’ (|0d0a0d0a| or ‘\r\n\r\n’)’ indicating an end of a Request message may not be transmitted. The web server may maintain a corresponding connection in an open state, until a Get Request message ends, that is, until a complete Request message is completely received. As a result, all connections of the web server may be filled with connections caused by the attack, and a new connection may not be connected any more.
Currently, to defend the slowloris attack, an IIS web server sets a timeout value when receiving a request header. When a complete request header message is not received within a timeout time, the IIS web server may close a corresponding connection. However, since such a defense scheme is not applied in the Apache web server, the Apache web server is still vulnerable to a corresponding attack.
An attack tool using slow request bodies is classified into two types: a RUDY and an OWASP HTTP post tool that may use the same attack scheme. When a complete HTTP Post Request Header message is transferred to a web server targeted for an attack, an attack may be attempted by very slowly transmitting a small amount of a body part. Actually, there is an example in which an attack is attempted by transmitting 1 byte of the body part per 110 seconds.
Accordingly, it is difficult to defend RUDY or OWASP HTTP post attack, using a scheme of setting a timeout of a request header, such as a slowloris attack, and depending the slowloris.
A corresponding attack may be performed using a scheme by which a client transmits an HTTP Post Request message when normal TCP session connection is established between the client and a server. When a content-length field in the HTTP Post Request message is set to ‘20000’ and the HTTP Post Request message is transmitted, the server may ensure resources of the server corresponding to 20,000 bytes, and may open a corresponding session until all data is received. However, the client may transmit 1 byte of a Post Body message per 1 second, and the server may maintain the session to be open while all of the data is received, namely during 20,000 seconds (about 5 hours and 30 seconds).
Since most web servers store a body of 2 gigabytes (GB) or greater for a single HTTP Post Request, connection resources may be occupied for a very long period of time. Additionally, a web server may basically enter a service denial state by only 20,000 connections resources, regardless of hardware performance (a high-performance CPU, a memory, and the like).
Accordingly, all connection resources that may be provided by a corresponding server may be easily consumed using only a small number of attack systems, which may result in a success in a DDoS attack.
Currently, to detect such an attack, RequestReadTimeoutbody may be set to ‘30’ through a ModSecurity, namely an open source web firewall for the Apache web server, and may defend the attack. Such a scheme may be performed to detect the attack when a request body is not received for 30 seconds.
However, when an attack is performed by an infected zombie, the above scheme may not be regarded as an effective scheme due to an increase in a probability of a DoS state, since 30 seconds are too long to consume all sessions that may be provided by a corresponding server.
Additionally, there is a scheme of limiting a set amount of data of a web site input form, and detecting an attack when a size of data input to a POST exceeds a preset amount. For example, since both an ID field and a password field do not exceed 20 bytes in general, a login form may prevent the ID field and the password field from exceeding corresponding sizes. Conversely, when the ID field and the password field exceed corresponding sizes, an attack may be detected. However, since all range values that may be included in a corresponding form need to be recognized with respect to a characteristic of a web server and all POST forms, a performance issue may occur. Additionally, the scheme may be ineffective due to a limitation in practical application.
As described above, since a fast DDoS attack of a typical flooding performs an attack using a large amount of traffic, an amount of traffic is significantly increased compared to a normal case, and the attack may be easily detected. However, since the above-described slow DDoS attack using the connection resource consumption uses the weak point of an HTTP by using only a small amount of traffic in normal TCP connection, it is very difficult to detect the attack.